Smart mechanism for multi-client bidirectional optical channel protection scheme

ABSTRACT

Methods and apparatus for efficiently allowing protection switch information to be communicated on bidirectional lines are disclosed. According to one aspect of the present invention, a method for communicating protection switch information from a first network element to a second network element across bidirectional links that include at least one working line and a protection line involves obtaining a generic framing protocol GFP frame at the first network element. The GFP frame has a payload area with a client payload field. The method also includes defining a command field associated with the GFP frame that is in the payload area but not in the client payload field, and storing protection switch information in the command field.

BACKGROUND OF THE INVENTION

1. Field of Invention

The present invention relates generally to optical networks. Moreparticularly, the present invention relates to a smart management framein which the payload of the frame is used to transport protection switchinformation.

2. Description of the Related Art

Within Synchronous Optical Network (SONET) and Synchronous DigitalHierarchy (SDH) transport networks, automatic protection switching (APS)enables working interfaces to be protected by backup interfaces. When aworking interface fails, a backup interface assumes the traffic load ofthe working interface. In other words, APS provides the capability todetect a failure in an interface and to switch the traffic load of thefailed interface to another interface.

Protection switching is typically implemented through the utilization ofK1 and K2 bytes in a line overhead of a SONET or SDH signal. When asignal failure is detected or when signal degradation is detected,protection switching may be initiated. K1 and K2 bytes are used toeffectively signal a line level protection switch.

With reference to FIGS. 1A and 1B, protection switching which uses K1and K2 bytes in the line overhead of a signal will be described. FIG. 1Ais a diagrammatic representation of a near end and a far end that are incommunication over a plurality of working links and a protection link.That is, FIG. 1A depicts a 1:N protection scheme. It should beappreciated that N is generally an integer which has a value between oneand fourteen, inclusive. Optical signals are typically sent from asource or a near end 102 to a destination or a far end 106 over workinglinks 110 a, 110 b. A protection link 114 is generally not used untilone of working links 110 a, 110 b fails. As shown, working links 110 a,110 b and protection link 114 are bidirectional.

When working link 110 a fails, as indicated in FIG. 1B, far end 106detects the failure and sends a message using bits of a K1 byte to nearend 102 over protection link 114. Generally, bits five through eight ofa K1 byte are used to hold a switch action channel request. Hence, bysending a message in bits five through eight of the K1 byte, far end 106requests that near end 102 switch from transmitting over working links110 a, 110 b to transmitting over working link 110 b and protection link114. In response to the message sent by far end 106, near end may switchfrom transmitting on working links 110 a, 110 b to transmitting onworking link 110 b and protection link 114.

With reference to FIG. 2, the steps associated with implementingprotection switching in a 1:N protection architecture will be described.A process 200 of implementing protection switching begins at step 204 inwhich a far end detects a failure on a working link between a near endand the far end. The working link has an associated protection link.Upon detecting a failure, the far end sends a message in a K1 byte of aframe to the near end in step 208. The K1 byte generally includes bitsthat indicate a switching priority and bits that indicate a requestedswitch action.

In step 212, the near end receives the message and switches traffic fromthe working link with the failure, i.e., the failed working link, to theprotection link associated with the failed working link. Then, in step216, the near end sends a message using a K1 byte and a K2 byte of aframe to the far end. Bits in the K2 byte are used to indicate a channelnumber for data traffic sent over the protection link, and bits inn theK1 byte are used to send a reverse request. The reverse request istypically used to initiate a bidirectional switch action.

The message sent by the near end is received by the far end, and in step220, the far end switches to the protection link to receive traffic.After the far end switches to the protected link, the far end switchestraffic from the failed working link to the protection link to transmittraffic in step 224. That is, the far end sets up to transmit packets,as well as to receive packets, using the protection link. Once the farend switches traffic to the protection link, the process of implementingprotection switching is completed.

While the use of K1 and K2 bytes in SONET and SDH signals is generallyeffective for implementing APS, K1 and K2 bytes each only include onebyte. The amount of information which may be transmitted using two bytesmay be limiting is situations in which it would be desirable to transmitmore information relating to APS. Further, K1 and K2 bytes are nottransparent to a SONET or SDH cloud.

Therefore, what is desired is a method and an apparatus which allowsinformation associated with a protection switch to be transmitted suchthat the information is not limited to a maximum of two bytes, and suchthat the information is transparent to a SONET or SDH cloud. That is,what is needed is a system which allows information typically associatedwith K1 and K2 bytes to be transmitted in bytes other than standard K1and K2 bytes.

SUMMARY OF THE INVENTION

The present invention relates to transmitting information associatedwith automatic protection switching in a command field of a genericframing protocol (GFP) frame. According to one aspect of the presentinvention, a method for communicating protection switch information froma first network element to a second network element across bidirectionallinks that include at least one working line and a protection lineinvolves obtaining a generic framing protocol GFP frame at the firstnetwork element. The GFP frame has a payload area with a client payloadfield. The method also includes

defining a command field associated with the GFP frame that is in thepayload area but not in the client payload field, and storing protectionswitch information in the command field.

In one embodiment, the command field has a size of up to approximatelyfour bytes. In another embodiment, the protection switch informationincludes channel selection information bits associated with at least onechannel of the protection line and protection switch priority bits.

The inclusion of protection switch information, e.g., information thatis generally associated with K1 and K2 bytes of line overhead, in acommand field appended at an end of an overall payload area of a GFPframe allows the protection switch information to be substantiallytransparent to a SONET or SDH cloud. Further, such information mayinclude up to four bytes, which allows a higher level of protectionswitch information to be transmitted than would be transmitted instandard K1 and K2 bytes.

According to another aspect of the present invention, a method forprocessing protection switch information associated with a protectionswitching arrangement that includes at least one bidirectional primarylink and a bidirectional secondary link includes obtaining a GFP frameand reading a protection switch information bit that is stored in acommand field of the GFP frame. In one embodiment, the method includes

storing an additional protection switch information bit in the commandfield, and sending the GFP frame including the additional protectionswitch information bit on the bidirectional secondary link.

In accordance with yet another aspect of the present invention, a GFPdata structure includes a core header and a payload area. Included inthe payload area are a payload header, a payload field, and a commandfield. The command field is substantially appended to the payload fieldand arranged contains protection switch information. In one embodiment,the command field is up to approximately four bytes in size. In anotherembodiment, the command field contains information associated with K1and K2 bytes.

These and other advantages of the present invention will become apparentupon reading the following detailed descriptions and studying thevarious figures of the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may best be understood by reference to the followingdescription taken in conjunction with the accompanying drawings inwhich:

FIG. 1A is a diagrammatic representation of a near end and a far endthat are in communication over a plurality of working links and aprotection link.

FIG. 1B is a diagrammatic representation of a near end and a far endthat are in communication over a plurality of working links and aprotection link, i.e., near end 102 and far end 106 of FIG. 1A, in whicha working link has failed.

FIG. 2 is a process flow diagram which illustrates one method ofimplementing protection switching.

FIG. 3A is a diagrammatic representation of a generic framing procedure(GFP) frame.

FIG. 3B is a diagrammatic representation of a GFP frame, i.e., GFP frame300 of FIG. 3A, with protection switch information in a payload area inaccordance with an embodiment of the present invention.

FIG. 3C is a diagrammatic representation of a GFP frame, i.e., GFP frame300 of FIG. 3A, with protection switch information bits in a protectionswitch information field of a payload area in accordance with anembodiment of the present invention.

FIG. 4 is a process flow diagram which illustrates one method ofprocessing a message that includes protection switch information storedin a payload area in accordance with an embodiment of the presentinvention.

FIG. 5 is a process flow diagram which illustrates one method ofprocessing a client signal failure indication in accordance with anembodiment of the present invention.

FIG. 6A is a diagrammatic representation of a near end and a far endwhich are associated with a protection scheme in which a working linkhas failed in accordance with an embodiment of the present invention.

FIG. 6B is a diagrammatic representation of a near end, i.e., near end602 of FIG. 6A, sending a client signal failure indication to a far end,i.e., far end 606, in accordance with an embodiment of the presentinvention.

FIG. 6C is a diagrammatic representation of a far end, i.e., far end 606of FIG. 6 a, sending a client signal failure indication with protectionswitch information to a near end, i.e., near end 602, in accordance withan embodiment of the present invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

A generic framing procedure (GFP) provides a framing mechanism thatenables a substantially direct mapping of different data traffic typesinto frames that are compatible with a Synchronous Optical Network(SONET) protocol and a Synchronous Digital Hierarchy (SDH) protocol. GFPeffectively defines a framing approach that enables different traffictypes to be transported across a SONET or an SDH network. Hence, usingGFP, protocols such as Ethernet and Fiber Channel may be carried overSONET and SDH networks.

Adding protection switch information, e.g., information associated withautomatic protection switching (APS), in a command field of an overallpayload area of a GFP frame allows the protection switch information tobe substantially transparent to a SONET or SDH cloud. Hence, between anear end and a far end of a transmission, protection switch informationmay be efficiently transmitted and received. In addition, a commandfield that is added to the end of a client payload field in a GFP framemay include up to four bytes, thereby allowing a higher amount ofprotection switch information to be transmitted than would betransmitted in standard K1 and K2 bytes in line overhead. The protectionswitch information is typically control information that may be used toenable protection switching to occur.

FIG. 3 a is a diagrammatic representation of a GFP frame. A GFP frame300 includes a core header 304 and a payload area 308. Core header 304,which has approximately four bytes, includes a payload length indicator312 and header error correction bits 316. Payload length indicator 312is typically two bytes that give the length of payload area 308, whileheader error correction bits 316 are generally sixteen bits or two bytesthat contain information which allows for errors within core header 304to be corrected. Specifically, header error correction bits 316 allowscyclic redundancy check errors to be detected within payload lengthindicator 312.

In addition to including payload header 320, payload area 308 alsoincludes a client payload field 324 and a frame checking sequence (FCS)field328. Payload header 320 defines a type of information that is beingtransported, as well as the contents of client payload field 324. Thetype of information being transported may be, but is not limited to,client management frames and client information frames. Payload header320 generally includes a header error correction field 332, a type field336, and an extension field 340. Header error correction calculationfield 332, which is approximately two bytes in length, may containcyclic redundancy check codes used to detect and to correct cyclicredundancy check errors in payload header 320. Type field 336 istypically two bytes that specify an information type for the contents ofclient payload field 324. Type field 336 also identifies that FCS 328 ispresent at the end of frame 300, specifies a type associated withextension 340, and also defines the type of data present in the clientpayload field 324. Extension field 340, which may have a length ofbetween approximately zero bytes and approximately sixty bytes, maycontain information pertaining to frame 300.

Client payload field 324 may include up to approximately 65,541 bytes,and FCS field 328 may include up to approximately four bytes. Clientpayload field 324 generally contains client data, or native packetinformation. FCS field 328, in the described embodiment, containsprotection switch information. The protection switch information mayinclude information that is typically contained in K1 and K2 bytes inline overhead. That is, FCS field 328 is effectively a command fieldthat may include, but is not limited to including, switch priorityinformation, a switch action request, and a channel number on which datais to be sent on a protection link. As shown in FIG. 3B, protectionswitch information field 328 is effectively appended onto client payloadfield 324, and is a part of a payload area within frame 300.

Protection switch information field 328 may include substantially anytype of information that may be used for APS signaling. As shown in FIG.3C, protection switch information field 328 may be divided into anynumber of sub-fields 328 a-d which may each contain any number of bitsup to a total of approximately four bytes over sub-fields 328 a-d.Although four sub-fields 328 a-d are shown, it should be appreciatedthat there may generally be any number of sub-fields 328 a-d. Sub-fields328 a-d may contain, as previously mentioned, information that selects achannel to be used by APS messages, information that selects a bridgedchannel, information that identifies an APS architecture, andinformation that identifies bidirectional transmission capabilities.Further, sub-fields 328 a-d may also contain condition information suchas switch priority information as mentioned above, and informationrelating to a type of request, e.g., a reverse request, or a reason fora switch request, e.g., a signal failure or a signal degrade.

With reference to FIG. 4, one method of processing a received clientmanagement frame with a command field that contains protection switchinformation will be described in accordance with an embodiment of thepresent invention. A method 400 of processing a client management framebegins at step 404 in which a near end or a source receives a messagethat contains protection switch information. In the describedembodiment, the message is a GFP frame with a command field thatincludes up to approximately four bytes of protection switchinformation.

After the near end receives the message, i.e., the current message orframe, the near end compares the contents contained in the command fieldof the current message to the contents of a command field of a previousmessage in step 408. That is, a comparison is made between the currentprotection switch information and previous protection switchinformation. A determination is then made in step 412 regarding whetherthe contents of the command fields are different. If it is determinedthat the contents of the command fields are the same, i.e., that thecurrent protection switch information is substantially the same as theprevious protection switch information, the indication is that noprotection switching is requested. Accordingly, the processing of aclient management frame with a command field that contains protectionswitch information is completed.

Alternatively, if the determination in step 412 that the contents of thecommand fields are different, the implication is that the far end whichsent the message detected a failure on a working link or received aclient signal failure indication. That is, if the contents of thecommand fields are determined to be different, then the indication isthat the far end has identified a failure on a working link and has senta switch action request to the near end in the current message. As such,process flow moves from step 412 to step 416 in which the near endgenerates an interrupt. Generating an interrupt may include ceasing tosend traffic on the working link identified as having failed. When theinterrupt is generated, new commands may be acquired, e.g., new commandsmay be acquired by a microprocessor of the near end from the far end.

In order for a near end to receive protection switch information from afar end, the far end may add protection switch information in a commandfield of a frame in which there is a client signal failure indication.Referring next to FIG. 5, one process of providing protection switchinformation from a far end to a near end will be described in accordancewith an embodiment of the present invention. A process 500 of providingprotection switch information begins at step 504 in which a far endreceives a client signal failure indication from a near end. The clientsignal failure indication is sent to the far end as a part of a clientmanagement frame, as will be appreciated by those skilled in the art.

Once the client signal failure indication is received, the far endperforms protection switching in step 508, i.e., the far end switches toreceiving traffic across a protection link. After the protectionswitching is performed at the far end, the far end builds a clientmanagement frame with a command field into which protection switchinformation is stored in step 512. As previously discussed, the commandfield may include up to approximately four bytes. In step 516, the framebuilt by the far end is forwarded to the near end, and the process ofproviding protection switch information to a near end is completed.

When a far end sends a client management frame with protection switchinformation to a near end, the far end may send the client managementframe on a protection link as well as on any working or primary linkswhich have not been identified as having a failure associated therewith.By way of example, when the far end and the near end are associated witha 1:N protection scheme and one working or primary link is identified asfailed, the client management frame with protection switch informationis generally sent on the remaining “N−1” non-failed working links andthe protection or secondary link.

FIG. 6A is a representation of a near end and a far end within a networkin which the near end has an associated failure in accordance with anembodiment of the present invention. A near end 602 and a far end 606are in communication over at least one bidirectional working or primarylink 610 and a bidirectional protection or secondary link 614. It shouldbe appreciated that although only one bidirectional working link 610 isshown, the number of bidirectional working links which may be consideredto be included in a cloud between near end 602 and far end 606 may varywidely. Generally, near end 602 and far end 606 may each have componentssuch as processors and memories. In one embodiment, near end 602 and farend 606 may be network elements such as routers, clients, and servers.Further, near end 602 and far end 606 may include muxponders.

When a failure is associated with near end 602 or, more specifically,when a failure affects working link 610, a client signal failureindication frame 630 may be sent across failed working link 610 to farend 606 as shown in FIG. 6B. Client signal failure indication frame 630may be embodied in a carrier wave signal when sent across failed workinglink 610. It should be appreciated that the client signal failureindication frame 630 may be a client management frame that indicates aclient signal failure when the client management frame is incomplete. Aspreviously mentioned, a client management frame is generally a GFPframe.

After far end 606 receives client signal failure indication frame 630,far end 606 effectively detects a failure associated with working line610, and initiates a protection switch. Far end 606 may append up toapproximately four bytes onto client signal failure indication frame 630as a command field. The command field, which is part of a payload areaof client signal failure indication frame 630, is arranged to include atleast some protection switch information. The protection switchinformation may be, in one embodiment, up to a four byte representationof information that is typically contained in the K1 and K2 bytes inline overhead. FIG. 6C is a representation of near end 602 and far end606 after far end 606 sends protection switch information to near end602. Once protection switch information is added into a command field inclient signal failure frame 630, client signal failure frame 630′, whichincludes the command field in which protection switch information iscontained, is sent to near end 602 over protection line 614. Near end602 may process client signal failure frame 630′ by using the protectionswitch information contained therein to switch transmission from failedworking line 610 to an appropriate channel on protection line 614. Theinformation regarding the channel onto which transmissions or datatraffic has been switched may be sent to far end 606 by near end 602 ina command field of a subsequent frame.

Although only a few embodiments of the present invention have beendescribed, it should be understood that the present invention may beembodied in many other specific forms without departing from the spiritor the scope of the present invention. By way of example, although acommand field in which protection switch information is contained hasbeen described as being added or otherwise appended to a clientmanagement frame that includes a client signal failure indication, acommand field may generally be added to any client management frame.That is, protection switch information may be transmitted from a far endto a near end as a part of substantially any client management frameafter a far end receives a client signal failure indication.

A network element that serves as a far end, e.g., network element 606 ofFIG. 6A, may be arranged to include either or both hardware and softwarecode devices that enable protection switch information to be added intoa GFP frame. Such a network element, when arranged to support softwarecode devices, may include memory or be arranged to support acomputer-readable medium that enables software code devices to be storedthereon, as well as a processor that allows the software code devices toexecute. Any hardware devices may be implemented, in one embodiment, asan application specific integrated circuit.

The steps associated with the methods of the present invention may varywidely. Steps may be added, removed, altered, and reordered withoutdeparting from the spirit of the scope of the present invention.Therefore, the present examples are to be considered as illustrative andnot restrictive, and the invention is not to be limited to the detailsgiven herein, but may be modified within the scope of the appendedclaims.

1. A method for communicating protection switch information from a firstnetwork element (far end) to a second network element (near end) acrossbidirectional links, the bidirectional links including at least oneworking line and a protection line, the method comprising: obtaining ageneric framing protocol (GFP) frame at the first network element, theGFP frame having a payload area, the payload area including a clientpayload field; defining a command field associated with the GFP frame,the command field being defined substantially within the payload areabut not in the client payload field; and storing protection switchinformation in the command field.
 2. The method of claim 1 whereindefining the command field includes appending the command field onto anend of the client payload field.
 3. The method of claim 1 wherein thecommand field has a size of up to approximately four bytes.
 4. Themethod of claim 1 wherein the protection switch information includeschannel selection information bits associated with at least one channelof the protection line.
 5. The method of claim 4 wherein the protectionswitch information further includes a protection switch priority bits.6. The method of claim 1 wherein the GFP frame is a management frame,the GFP frame including a signal fail indication associated with the atleast one working line.
 7. The method of claim 6 wherein obtaining theGFP frame at the first network element includes receiving the GFP framefrom the second network element on the at least one working line.
 8. Themethod of claim 1 further including: sending the GFP frame with thecommand field to the second network element on at least the protectionline.
 9. A first element, the first element being arranged tocommunicate protection switch information to a second element across atleast one bidirectional link, the at least one bidirectional linkincluding at least one working line and a protection line, the firstelement comprising: means for obtaining a generic framing protocol (GFP)frame at the first element, the GFP frame having a payload area, thepayload area including a client payload field; means for defining acommand field associated with the GFP frame, the command field beingdefined substantially within the payload area but not in the clientpayload field; and means for storing protection switch information inthe command field.
 10. The first element of claim 9 wherein the commandfield is arranged to be appended onto an end of the client payloadfield, the command field including up to approximately four bytes. 11.The first element of claim 9 wherein the protection switch informationincludes channel selection information bits associated with at least onechannel of the protection line.
 12. The first element of claim 9 whereinthe GFP frame is a management frame, the GFP frame including a signalfail indication associated with the at least one working line, andwherein the means for obtaining the GFP frame at the first elementinclude means for receiving the GFP frame from the second element on theat least one working line.
 13. The first element of claim 9 furtherincluding: means for sending the GFP frame with the command field to thesecond element on at least the protection line.
 14. A first element, thefirst element being arranged to enable protection switch information tobe communicated across at least one bidirectional link, the at least onebidirectional link including at least one working line and a protectionline, the first element comprising: devices that cause a generic framingprotocol (GFP) frame to be obtained, the GFP frame having a payloadarea, the payload area including a client payload field; devices thatcause a command field associated with the GFP frame to be defined, thecommand field being defined substantially within the payload area butnot in the client payload field; and devices that cause protectionswitch information to be stored in the command field.
 15. The firstelement of claim 14 wherein the command field is arranged to be appendedonto an end of the client payload field, the command field including upto approximately four bytes.
 16. The first element of claim 14 whereinthe protection switch information includes channel selection informationbits associated with at least one channel of the protection line. 17.The first element of claim 14 wherein the GFP frame is a managementframe, the GFP frame including a signal fail indication associated withthe at least one working line, and wherein the devices that cause theGFP frame to be obtained include devices that cause the GFP frame to bereceived on the at least one working line.
 18. The first element ofclaim 14 further including: devices that cause the GFP frame to be sentwith the command field on the protection line.
 19. The first element ofclaim 14 wherein the first element is a computer-readable medium, andthe devices are code devices.
 20. A method for processing protectionswitch information associated with a protection switching arrangementthat includes at least one bidirectional primary link and abidirectional secondary link, the method comprising: obtaining a genericframing protocol (GFP) frame, the GFP frame having a payload area, thepayload area including a command field in which at least one protectionswitch information bit is arranged to be stored; and reading the atleast one protection switch information bit from the command field. 21.The method of claim 20 further including storing at least one additionalprotection switch information bit in the command field; and sending theGFP frame with the at least one additional protection switch informationbit on the at least one bidirectional secondary link.
 22. The method ofclaim 20 wherein the command field includes up to approximately fourbytes.
 23. The method of claim 20 wherein the at least one protectionswitch information bit includes at least one bit arranged to specify arequested switch action.
 24. The method of claim 23 further including:performing the requested switch action.
 25. A first element, the firstelement being arranged to process protection switch informationassociated with a protection switching arrangement that includes atleast one bidirectional primary link and at least one bidirectionalsecondary link, the first element comprising: means for obtaining ageneric framing protocol (GFP) frame, the GFP frame having a payloadarea, the payload area including a command field in which at least oneprotection switch information bit is arranged to be stored; and meansfor reading the at least one protection switch information bit from thecommand field.
 26. The first element of claim 25 further including meansfor storing at least one additional protection switch information bit inthe command field; and means for sending the GFP frame with the at leastone additional protection switch information bit on the at least onebidirectional secondary link.
 27. The first element of claim 25 whereinthe command field includes up to approximately four bytes.
 28. The firstelement of claim 25 wherein the at least one protection switchinformation bit includes at least one bit arranged to specify arequested switch action.
 29. The first element of claim 28 furtherincluding: means for performing the requested switch action.
 30. A firstelement, the first element being arranged to process protection switchinformation associated with a protection switching arrangement thatincludes at least one bidirectional primary link and at least onebidirectional secondary link, the first element comprising: devices thatcause a generic framing protocol (GFP) frame to be obtained, the GFPframe having a payload area, the payload area including a command fieldin which at least one protection switch information bit is arranged tobe stored; and devices that cause the at least one protection switchinformation bit to be obtained from the command field.
 31. The firstelement of claim 30 further including devices that cause at least oneadditional protection switch information bit to be stored in the commandfield; and devices that cause the GFP frame with the at least oneadditional protection switch information bit to be sent on the at leastone bidirectional secondary link.
 32. The first element of claim 30wherein the command field includes up to approximately four bytes. 33.The first element of claim 30 wherein the at least one protection switchinformation bit includes at least one bit arranged to specify arequested switch action and the first element further includes devicesthat cause the requested switch action to be performed.
 34. The firstelement of claim 30 wherein the first element is a computer-readablemedium and the devices are computer code devices.
 35. A generic framingprotocol (GFP) data structure comprising: a core header; and a payloadarea, the payload area including a payload header, a payload field, anda command field, the command field being substantially appended to thepayload field and arranged to contain protection switch information. 36.The GFP data structure of claim 35 wherein the command field is up toapproximately four bytes in size.
 37. The GFP data structure of claim 35wherein the command field is arranged to contain information associatedwith K1 and K2 bytes.
 38. The GFP data structure of claim 35 wherein thecommand field is arranged to contain bits that specify a switch actionchannel request.
 39. The GFP data structure of claim 35 wherein the GFPdata structure is transparent to a SONET or SDH cloud.